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A Low-cost Development Tool 



Article ID# 1001 

Intel's EP80960CX Evaluation Platform 
offers a low-cost hardware tool for execut- 
ing and debugging code. Featuring the 
i960* CA processor, it upgrades easily to 
the i960 CF processor, the newest and high- 
est-performance member of Intel's family 
of 32-bit embedded microprocessors. 

The board includes a high- 
performance interleaved 
DRAM subsystem that oper- 
ates with two wait state (2-0-0- 
0) burst reads and zero wait 
state (0-0-0-0) posted writes. 
The 2-MB memory subsystem, 
expandable up to 16 MB, 
employs standard 70-ns 
DRAM SIMMs and runs at 
frequencies up to 33 MHz. 

The board also features an 
I/O subsystem and an 
advanced set of peripheral 
devices for benchmarking and 
debugging application code 
written for i960 CA/CF embed- 
ded processors. Also, an X-Bus 
both accepts expansion cards and external 
devices, and gives direct access to the 
processor's bus and control signals. 

The EP80960Cx includes an on-board, 
EPROM-based MON960 monitor with 
such popular features as a single-line 
assembler/disassembler, single-step pro- 
gram execution and software breakpoints. 
Also available is a complete code develop- 
ment environment with tools like Intel's iC- 
960 or GNU/960 compilers. 

The complete package also includes a 
power supply, nine-pin PC /AT RS-232 ser- 
ial connector and a 2S-pin parallel port and 



cable for downloading software. Included as 
well are diskettes of the MON960 host soft- 
ware; design and library files; an example 
program; and the EP80960Cx User's 
Mantial. The mannal includes board 
schematics, parts list, programmable logic 
device equations, and step-by-step instruc- 
tions on how to compile, assemble, link, 
download and execute the esample program. 




Figure 1. EP80960Cx Board 

EP80960CX Features 

■ 33-MHz Execution Speed 

■ 32-KB EPROM for 80960CA MON960 
Target Operating Firmware 

■ Two-M B Fast Page Mode DRAM*, 
Expandable to 16 MB 

■ Concurrent Interrogation of Memory 
and Registers 

■ Centronics Port for Parallel Downloads 



*A DRAM subsystem with zero wait state posted 
writes (0-0-0-0) and two (2-0-0-0) wait state reads. 
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Changing Our Way of Thinking 



We recently finished several projects using 
fuzzy logic on Intel microcontrollers and 
Tnicroprocessors. You can read about our 
results in the Fuzzy Logic Applications handbook 
(order number 272589-001). 

In addition to the encotiraging results, that experi- 
ence changed our approach to problem solving. All of 
the team members had been schooled and were well- 
disciplined in classic methods. We could define the 
parameters and write an eqtiation or develop an algo- 
rithm to describe the activity. Newton, Galileo and 
Laplace, among other pioneers of the past, would have 
been proud. 

But something curious happened along the way. We 
had purposely selected problems that were difficult to 
describe by an equation or, if they could be described, 
the equation was extremely difficult to solve. So here 
we were with inputs, a desired result and no practical 
ecpjation to relate the two. At first we felt frustrated; 
our acquired skills provided little, it seemed, in the 
way of a solution. But then we realized that problem 
solving is problem solving, no matter how you do it. 

Rather than develop a solution that was described 
by parameters like resistance, capacitance and mass — 
which would result in a precisely inexact equation — 
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we looked at the problem as a whole. We were able to 
incorporate the effects of secondary, tertiary and nth- 
order elements. In othir words, vs?e looked at the situa- 
tion rather than its parameters. To misapply Newton's 
Third Law, it was a case of action and reaction. 

Rather than tightly touple the input to the output by 
means of an equation, we described the situation in 
broad terms and rules. The change in our thinking was 
startling. Rather than ask "What can it do?", the ques- 
tion became "What shduld it do?" In other words, the 
solution was more in tune with the problem rather than 
with an inexact model of the problem. 

Despite its simplicity, fuzzy logic allows a much 
richer relationship between the inputs and the result. 
Consequently, it will provide new and better solutions 
to old problems, and solutions to problems that are 
presently beyond us. Fuzzy logic and its cousins, neur- 
al networks and ehaos [theory, offer a new set of c^a- 
bilities. 

Come on in, the water's fine. 



Joe Altnether 

Fuzzy Logic Program Director 
Embedded Microcontroller Division 
Int©! Corporation 



More Copies 



Need more copies of this issue of the Embedded 
Applications Journal? Please call Intel Literature 
Fulfillment at 800-468f8118 in the U.S. and Canada 
or +44(0)793-431 1 55 in Europe and ask for order 
#241294-011. 
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Feature Articles 

Implementing Additional External Interrupts on 
MCS®51 Microcontrollers, Part 2 



S.S. Dang and Y.Y. Soh 
Applications Engineers 
Intel Corporation 
Article ID#1002 



In this second part of a two-part series, we discuss how 
timer 0, timer 1 and the PCA counter can serve as 
external interrupt inputs, supplementing dedicated 
external interrupt sources INTO and INTl. Part I, 
which appeared in the previous isstte of Embedded 
Applications Journal, showed 
how to use timer 2 for the same 
purpose. 



■ Clear the gate bit (GATE = 0) 

For the TCON register: 

■ Set the counters running (TRO = 1, TRl = 1) 

■ Clear the counter overflow flags 

(TFO = 0, TFl =0) 

■ If external interrupts and 1 are being used, set 
external interrupt control bits and flags (lTO/1, 
IEO/1) 



Timer 0, 1 

Getting timer and timer 1 to 
work as external interrupts is as 
simple as causing them to over- 
flow and, in fact, uses that mech- 
anism: A high-to-low transition 
applied to pin TO or Tl will 
cause the corresponding counter, 
if preloaded with FFH, to over- 
flow. The counter overflow, in 
turn, generates an interrupt. That 
interrupt points to address OBH 
for timer and address OIBH for 
timer 1. 

The service routine for these 
timer-based interrupts must 
invoke the auto-reload mode and 
reload the coimter registers with 
FFH. To configure timers and 1 
to the 8-bit auto-reload counter 
overflow mode, preload the 
counter registers THx, TLx with 
FFH and set the TMOD and 
TCON registers as follows: 



SINCLUDE (eSlPX.KBG) 



ORG 
AJMP 
ORG OBH 
AJMP TO_ISR 
ORG OIBH 
AJMP Tl ISR 



OOH, 

TQl INIT 



; Registers declaration 

/■Initialize Timer 0/1 as external interrupt 
/•Timer 0/1 initialization 



; Timer interrupt vector 
_ ; Timer 1 interrupt vector 

;This is the initialization routine for timers and 1 



ORG OlOOH 
T01_INIT: MOV TMOD, #66H 

MOV TLO, #OFFH 

MOV THO, #OFFH 

MOV TLl, #OFFH 

MOV THl, #OFFH 

MOV IP, #OAH 
MOV IE, #8AH 
MOV TCON, #50H 

s 

SJMP $ 



flags 



; Set timer 0,1 as auto-reload event counter 

; Preload timer counter register 

/■Timer counter reload value 

;Preload timer 1 counter register 

; Timer 1 counter reload value 

;Set timer 0,1 interrupt priority 

; Enable timer 0,1 & global interrupt 

/■Set timer 0,1 run bits, clear interrupt 

/■Wait far interrupt 



This is timer interrupt service routine 

0_ISR: 

User' s routine here 

Interrupt flag TCON. 5 is cleared by hardware 
RETI 

This is timer 1 Interrupt service routine 



_ISR: 

User' s routine here 
Interrupt flag ICON. 7 
RETi 
END 



is cleared by hardware 



figure 1. Sample Program Using the Timer 0, I Counter Overflew Mode to 
Indicate an External Internet 



For the TMOD register: 

■ Set timers and 1 as external event counters 

(C/T# = 1) 

■ Put the counters in the 8-bit auto-reload mode 

(Ml = 1,M0 = 0) 



Figure I gives a sample program for setting the 
TMOD and TCON registers. 

This approach precludes the use of the other fea- 
tures of timers 1 and 0. In addition, port pins P3.4 (or 

Continued on page 4 



Continued from page 3 

TO) and P3.5 (or Tl ) must be dedicated to 
the external interrupts. Although the 
example shows both timers serving as 
external interrupt sources, it is also possi- 
ble to configure only one of the timers this 
way, leaving the other to operate as a 
timer. 

PCA 

Like timers and 1 , the microcon- 
troller's PCA counter can also be used as 
an additional external interrupt source. 
There are two approaches: The first uses 
the capture mode; the second, like the 
timers, uses the counter overflow mode. 

Capture Mode 



$ INCLUDE (C5 IPX. REG) 


; Register Declaration 


ORG OOH 




AJMP PCA INIT 


;PCA initialization 


ORG 033H 




AJMP PCA_ISR 


;PCA interrupt vector 


.-This is the PCA initialization routine 


ORG OlOOH 




PCA INIT: MOV CMOD, #:00H 


; Clear all unused bits 


MOV CCAPMO, #011H 


;PCA module negative edge capture 


mode 




MOV CCON, #00H 


; Clear PCA run bit & interrupt flags 


MOV IP, #40H 


; Set PCA interrupt priority 


MOV IE, #OCOH 


/Enable PCA & global interrupt 


SJMP $ 


/Wait for interrupt 


; This is the PCA interrupt service routine 


PCA_ISR: CLR CCON.O 


; Clear intearrBpt Hmg,. CCfO 


; User's routine here 




RETI 




END 





Figure 2. Sample Program Using PCA Module s Capture Mode as 
an Additional External Interrupt Source 



In the capture mode, a transition applied to pin 
CEXn generates an interrupt, which is vectored to the 
PCA interrupt vector address, 033H. The activating 
transition can be high-to-low, low-to-high or either by 
setting CCAPMn register bits CAPNn, CAPPn or 
both, respectively. For example, to configure PCA 
module for a high-to-low transition, set CMOD, 
CCAPMO and CCON registers as follows: 

In the CMOD register: 

■ Clear all unused bits (CIDL, WDTE, CPSl, CPSO, 
ECF = 0) 

In the CCAPMO register: 

■ Set PCA module as negative edge 
trigger on pin CEXO (CAPNO = 1) 

■ Enable the compare/capture interrupt (ECCFO = 1) 

■ Clear the remaining bits (ECOMO, CAPPO, 
MATO, TOGO and PWMO = 0) 

In CCON register: 

■ Clear PCA timer run bit (CR = 0), 

■ Clear the capture/compare interrupt flag (CCFO = 
0) in both initialization and interrupt service rotines 

■ Clear the unused flags (CF, CeF4, CCF3, CCF2, 

CCFl =0) 

Figure 2 shows a program that performs these 
ftmctions. 

In this approach, port pin PI. 3 or CEXO is dedicat- 
ed to the external interrupt. The remaining modules 
can be used normally, but they will share the same 



interrupt vector with module 0. In that case, interrupts 
from different modules can be differentiated by check- 
ing their interrupt flags. 

Counter Overflow Mode 

In the counter overflow mode, a high-to-low transi- 
tion applied to pin ECI will cause the PCA counter, if 
preloaded with FFH, to overflow. The coimter overflow, 
in turn, will generate an interrupt that will reference 

address 033H, the PCA interrupt vector. To configure 
the PCA in the counter overflow mode, preload the 
cotmter registers CH and CL with FFH. These two reg- 
isters need to be reloaded in the interrupt service rou- 
tine. Do not set the CCAPMn registers, but set the 
CMOD and CCON registers as follows: 

In the CMOD register: 

■ Set tiie PCA counter to use an external clocking 
source at pin ECI (CPS 1 , CPSO = 1 ) 

■ Enable the coimter overflow interrupt (ECF = 1) 

■ Clear the other bits if not used (CIDL, WDTE = 0) 

In the CCON register: 

■ Set the counter numing (CR =1) 

■ Clear the counter overflow flag (CF = 0) in both 
initialization and interrupt routines 

■ Clear the remaining imused flags (CCF4, CCF3, 
CCF2, CCFl, CCFO = 0) 

Figure 3 shows a program that performs these func- 
tions. 

Continued on page 8 
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Reviewing Real-Time 
Operating Systems 

Chris Briggs 
Intel Corporation 
Article ID#1003 

An operating system is code that provides services 
to manage a computer system s resources. It separates 
an application from hardware by treating the hardware 
as an abstract machine. In its simplest form, an operat- 
ing system performs only one task. Adding interrupts 
adds tasks in the form of the interrupt service routines. 
By adding interrupts and placing them into foreground 
and background segments, you begin to define the 
work of a modem operating system. 

A real-time operating system (RTOS) is one that 
performs its job — ^managing resources — ^within a given 
time constraint to meet a Systran's requirements. There 
is no specific response time tliat qualifies an operating 
system as "real time," although certain RTOSs may 
specify a response time in, say, X microseconds. 
Rather, it is up to the target application to define what 
"real time" means. Within that application, failing to 
meet the specified response time will cause severe con- 
sequences. 

A multitasking RTOS provides code for partitioning 
a design into multiple tasks, where each task runs inde- 
pendently of the others. Special techniques supply each 
task with the resources and service needed to guaran- 
tee that the application meets its time constraints. A 
common technique is to have a pre-emptive priority- 
based scheduler for the multitude of tasks. 

At the heart of an RTOS are real-time kernels or 
executives. A kernel is the part of a multitasking sys- 
tem responsible for the management of tasks; that is, 
managing the CPU's time and communication among 
the tasks. Small embedded systems that cannot afford 
the cost or complexity of a full-featured operating sys- 
tem that contains a file system, I/O management and 
netw orking functions can instead use a minimal real- 
time pre-emptive multitasking kernel. 

When an RTOS Makes Sense 

Some reasons to use an RTOS are that it: 

■ Provides a structure for overall system design 

■ Provides a common programming interface to all 
tasks 

■ Organizes system design into various functional 
models 



■ Permits independent work by a group of program- 
mers 

■ Reduces development time by performing simple 
tasks 

■ Helps to manage time-critical functions easily 

■ Simplifies debugging by decomposing system in 
many simple tasks 

■ Makes documentation easier to maintain 

■ Lowers long-term maintenance because of a modu- 
lar design 

Not surprisingly, there are also reasons not to use an 
RTOS. These are when: 

■ An application is very simple or has no time-criti- 
cal component 

■ System resources cannot support a full executive 

■ The budget cannot bear the potential royalty costs 
of a commercial product 

Focus on Features 

As with all tools, different RTOSs have a wide 
range of features. Fundamentally, the RTOS you 
choose should let you complete your project in the 
shortest time. Select an RTOS that meets your needs 
without modification. One that doesn't will be difficult 
and time-consuming to modify later. 

Also, don't make the mistake of selecting an RTOS 
simply because it is fast. If you do need the fastest 
response, expect to collect and compare performance 
data. But even then, it is more productive to put your 
energy into reviewing your system's timmg require- 
ments than into reviewing RTOS performance data. 

In most applications, performance is the prime 
issue. Ironically, designers often fear that using an 
RTOS will actually slow their system. But as proces- 
sors get faster and application programs get more com- 
plex, the relative time taken by the OS is shrinking. 

In addition to performance, some features to con- 
sider when shopping for an RTOS are debugging tools, 
"ROM-ability," processor support, connectivity, modu- 
larity, memory-management support, priority schedul- 
ing (fixed and dynamic), kernel size, cost and royalties, 
the availability of source code, development software 
cost. POSIX compliance, disk and diskless file options, 
the host computer, vendor support and training. 

As for memory requirements, these need not be 
' large. Many RTOSs have small kernels at their core. 
And where application memory requirements continue 
to grow, RTOS memory needs have not. Consequently, 
RTOSs have decreased as a percentage of a system's 
total memory needs. Also, memory-management units 
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are moving into the embedded world. As they become 
more prominent, memory concerns should fade. 

Functionality, cost and support are also important 
concerns. Functionality varies widely, ranging from a 
simple kernel to a full-blown operating system with 
file and networking features. As for cost, many kernels 
can be had \\ ithout paying royalties. For those that do 
cost, the price can often be negotiated. Like fimctional- 
ity, cost varies widely depending on features and sup- 
port. Make sure that you know what you're paying for. 

Typical RTOSs run on Unix or PC hosts. Self-host- 
ed systems can serve as a development environment 
and in the target environment. Historically, these have 
more features and functions, but less raw performance 
than kernels. Kernels or executives require that devel- 
opment be done on a separate host and operating sys- 
tem platform. 

In the past, the highest performance applications 
have been handled by kernel-based systems. However, 
this distinction is blurring as self-hosted systems have 
developed "ROM-able" kernels that improve then real- 
time performance. At the same time, kernels are 
improving their development environment and func- 
tionality with, for ©tample, I/O and file-system fea- 
tures. 

Architecture-independent RTOSs are available on a 
mmiba- of target and host platforms. Companies that 

offer them frequently port the RTOS to as many plat- 
forms as possible. In contrast, proprietary RTOSs 
come from hardware-oriented firms that limit them to 
their platform. Howevor, the trend has been for hard- 
ware-oriented companies to move aw^ firom propri- 
etary software. 

Other RTOS market trends are: 

■ As the price of faster and more sophisticated CPUs 
drops, the impetus is to use these processors to 

build more sophisticated systems. One way to 
extend a system's life is to leverage the use of exist- 
ing code, such as an RTOS. 

■ As RTOSs become less expensive, many companies 
that sell only RTOSs will be forced to join with 
other tool vendors to create integrated design envi- 
ronments. 

■ RTOSs are migrating from high-end Unix plaforms 
to price-sensitive Windows* -based PCs. As this 
happens, royalty-fi^e RTOSs will be bundled with 
compilers, debuggers and prafonnance analysis 
tools. 



■ Increasingly, RTOS support is appearing for digital 
signal processing (DSP) and reduced instruction set 
computer (RISC) architectures. 

■ High-end systems will continue to add capabilities. 
Among these are performance analysis, target sim- 
ulation, automated configuration utilities, board- 
suppoi t-gcneration packages and market-specific 
enhancements. Others include integrated configura- 
tion management, RTOS "awareness" in all tools, 
device driver libraries and hooks to block-level pro- 
gramming. 

■ Many RTOSs work with an integrated design envi- 
ronment, particularly in the 32-bit market. 

■ Expect to see increased vertical integration as third- 
party vendors (TPVs) optimize kernels. As RTOSs 
become similar, they will be differentiated by the 
vertical mailcets they serve, such as multimedia. 

■ The growing popularity of Windows is lowering tilie 
cost of tool chains. 

■ As memory requirements climb with the growing 
complexity of applications software, the relative 

size of RTOSs is dropping as a percentage of memory. 

In Summary 

This article has attempted to introduce you to real 

time operating systems (RTOSs). Do you need an 
RTOS for your application? It s up to you to decide. 
The reading list below should help you make that deci- 
sion. If you do, remranber that the RTOS industry is a 
mature one, and it is usually a better choice to buy 
from an established industry leader than from a new 
player. Today you can select fiom a number of vendors 
who support Intel's Embedded Architectures. 

Further Reading 

Real-Time Operating Systems, EDN, April 14,1994 
Real-Time Operating Systems, Embedded Systems 

Programming^. 1 /92 

Real-Time Buyer's Guide, Embedded Systems 
Programming, 8/93 

Real-Time Atlas, Embedded Systems Programming, 4/91 
ROMable Real-Time Kernels, Embedded Systems 
Programming, 2/90 

A Portable Real-Time Kernel in C, Embedded Systems 
Programming, 5/92 

Implementing a Real-Time Kernel, Embedded Systems 
Programming, 6/92 
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Measuring Voltages? "Look Ma, No A/D" 



Joe Altnether 

Fuzzy Logic Program Director 
Intel Corporation 
Article ID# 1004 



Sometimes a circuit must measure an analog signal, 
but its microcontroller either lacks an A/D converter or 
the signal to be measured exceeds the A/D's input rat- 
ing. If the system requires a fast conversion, the only 
choice may be to add a separate A/D circuit. But if the 
signal to measure is a supplemental or ancillary func- 
tion or a slowly varying voltage like temperature, other 
microcontroller resources can be harnessed to measure 
the voltage. 

One such A/D technique uses voltage-to-frequency 

conversion. The converter's pulse repetition rate, which 
varies with the amplitude of the input voltage, is mea- 
sured by the timer/counter structure of either an MCS® 
96 or an MCS 51 microcontroller. On one hand, this 
approach requires added components, and the time 
needed to measure the pulse width limits its response 
time. On the other han4 coupled with an optocoupler 
it can measure higher voltages than most A/D convert- 
ers and offer electrical isolation between input and out- 
put. 

Several circuits using this technique are described 
in the Motorola Thyristor Data Manual. One circuit 
uses a standard imijimction transistor (UJT) such as a 
2N4871, which has three terminals: ranitter, base 1, 
and base 2 (Figure 1). 



Measured Voltage 
J 


' E . 


4 Ou4>ut 


A2722-01 



Figure 1. Circuit Using Standard Unijunction 
Transistor (UJT) 

Between base 1 and base 2, the UJT acts like a 
resistor, forming a voltage divider at the emitter. The 
V-I curve (Figure 2) shows that only a small leakage 
current will flow when the emitter voltage is less than 
the emitter peak voltage. That's because the emitter is 



reverse biased. However, when the emitter voltage 
equals the emitter peak voltage, and the emitter current 
is greater than the peak point current, the device turns 
on, sharply dropping the base-to-base resistance. 



Peak Emitter Point 




Figure 2. Emitter V-I Curve 

Putting an R-C circuit on the emitter is one way to 

measure the time needed to reach the peak emitter, or 
trigger, voltage. That trigger voltage is directly propor- 
tional to Vo, the voltage across the RC network. 
Specifically the emitter voltage, v, is approximately 
equal to: 

V = Voe-t«c 

where Vo is the voltage across the R-C network, R is 
the resistance and C is the capacitance. 

Replacing Vq with the voltage we want to measure 
produces a trigger time that is proportional to that volt- 
age. The actual trigger time depends on the R-C time 
constant and the capacitance in particular. The value of 
the resistor R is bounded by the operation of the UJT 
as follows. 



Vs-Vp >R>Vs-Vv 



Ip Iv 

where Vs is the supply voltage and the Vp and Vv cor- 
respond to specific peak and valley parameters of the 
UJT. 

The higher the supply voltage, the higher the out- 
put. Typically, 20 volts is suitable. More important, 
however, is that the supply voltage must be greater than 
the expected maximum voltage to be measured. 

Temperature Sensitive 

Although UJTs can be temperature sensitive, care- 
fully selecting the base-circuit resistors can compen- 
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sate for this effect. A good start is 1 5 KQ. for the resis- 
tor from the supply voltage to base 2 of the UJT and 
about 27Q from base 1 to ground. 

To measure the time betw een edges of the trigger 
pulses, the output of the circuit is fed into the PCA of 
an MCS* 51 microcontroller or die HSIO or EPA of an 
MCS 96 microcontroller. The iirformation is converted 
to a volta^ amplitude by look-up table or by calcula- 
tion. 

As mentioned, this circuit can include an optocou- 
pler for translating voltage levels and for isolating the 
microcontroller from the measured voltage. An opto- 
coupler like the NEC PS9601 makes it possible to 
measure voltages that exceed the maximum voltages of 
the microcontroller, a useful qmUty in harsh industrial 
environments. 

Design Alternative 

An alternative circuit uses a program- 
mable unijunction transistor (PUT), which 
is a thryistor with a single anode (Figure 
3). Regenerative feedback of the pnpn 
structure produces an operating region 
with negative resistance, making the PUT 
well suited as an oscillator. 

With the gate voltage fixed, the device 
remains turned off until the anode voltage 
exceeds the gate voltage by one forward 
diode drop. Once the peak voltage is 
reached, the device fires. As shown, the 
output is isolated by a transistor at the 
PUT's cathode. It could also be isolated by 
an optocoupler. 

In a fixed-frequency oscillator, a resis- 
tive voltage divider sets the bias on the 
gate and establishes the peak voltage, Vp. 




A2723-01 



Figure 3. Circuit Using Programmable Unijunction 
Transistor (PUT) 



The R-C time constant controls the anode voltage and, 
as in the previous circuit, sets the time base. A transis- 
tor serves as a constant cinrent source, and peak volt- 
age on the gate is modulated by the signal to be mea- 
sured. When the signal to be measured is low, Vp is 
also low and the PUT &es faster than if Vp was higher. 

With capacitance values between 0.0047 and 0.01 
HF, a 1 5-volt span in the measured voltage will typical- 
ly produce a 3- to 5-ms change in period. Higher 
capacitance will increase that period, widening the 
span between minimum and maximum voltages. The 
downside of adding capacitance, however, is that it also 
increases the measurement time. 




Implementing Additional External Interrupts on 
MCS® 51 Microcontrollers, Part 2 

Continued fiom page 4 



In this approach, the remaining PCA featiu-es and 
modules caimot be used, and port pin PI .2 or ECI 
remains dedicated to the external interrupt. 

Conciusion 

The above examples show that timer 0, timer 1 and 
the PCA can be used as external interrupt sources in 
addition to timer 2 (as mentioned in Part 1 ) and the 
two existing, dedicated external interrupt sources. 



5INCLUDE (C51FX.REG) /Register Declaration 

ORG OOH 

AJMP PCA_INIT ;PCA initialization 

ORG 033H 

AJMP PCA_ISR ;PCA interrupt vector 

This is the PCA initialization routine 

ORG 01 OOH 

PCA_INIT: MOV CMOD, #07H ;PCA counter overflow mode 

MOV CH, #OFFH ; Preload PCA counter registers 

MOV CL, #OFFH 

MOV IP, #40H ;Set PC interrupt priority 

MOV IE, #OCOH /Enable PCA & global interrupt 

MOV CCON, #40H ;Set run bit, clear interrupt flags 

SJMP 5 /Wait for interrupt 

This is the PCA interrupt service routine 

PCA_ISR: CLR CCON. 7 /Clear Interrupt flag, CF 

MOV CH, #OFFH /Reload PCA counter registers 

MOV CL, #OFFH 

/ User's routine here 
RET I 
END 



Figure 3. Using the PCA Counter in the Overflow Mode as an 
Additional External Interrupt Source 



8 Q4, 1994 EMBEDDED APPLICATIONS JOURNAL 



A Low-cost Development Tool 

Continued from page I 

■ X-Bus Expansion Bus for Peripheral-to- 
CPU Interface 

■ 384 Software Breakpoints 

■ Code Disassembler 

■ High-Level Language Support 

■ RS-232 Port for Host and User Communication at 
up to 115.2Kbaud 

■ Memory Wait State Control for Memory 
Subsystem Simulation 



Prototype and Expansion Bus 

The X-Bus lets you prototype simple applications 
quickly. Two rows of header pins on the bus supply 
buffered address, data and control signals, as well as 
other signals that make it easy to attach simple periph- 
erals and I/O devices. The header pins also serve as 
logic-analyzer access points. 

Communication Link 

Communicates with the host computer via the RS- 
232 link at baud rates from 300 to 1 15,200. 
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Figure 2. Block Diagram of EP80960Cx Board 



Fast Page-mode DRAM SIMM Modules 

The EP80960CX Evaluation Platform's memory 
design takes advantage of the i960® CA/CF processor's 
burst mode bus for fast page-mode DRAM. For top 
performance, the memory subsystem combines bank 
interleaving, write posting and RAS interleaving. 

Concurrent Reading of Memory and Registers 

With the on-board MON960 monitor, you can read 
and modify internal registers and external memory 
while running your application program. 

High-speed Downloads 

A parallel interface serves as a full Centronics-com- 
patible, receive-only port for quickly downloading 
code or data to the board. 



Power Requirements 

A power supply delivers the required 5 VDC at 2.5 
A. The board also accepts +5 and +12 VDC for pro- 
gramming flash memory. 

Host System Requirements 

Although an Intel486-based PC is recommended, 
the platform connects to any Unix- or DOS-based sys- 
tem. A DOS-based host system must have at least: 

■ PC-DOS 3.2 or Later 

■ 512 KB of Memory 

■ A 1 .4-MB Floppy Disk Drive 

■ A Serial Port (COMl or COM2) 

A parallel port (LPTl) is desirable, but not required. 
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Monitoring Events With the 8XC196KC/KD's 
High Speed Input 



Sean Baartmans 
Applications Support 
Intel Corporation 
Article ID# 1005 



The high-speed input peripheral on the 
8XC196KC/KD serves a simple but useful function. 
Used mostly to monitor events, it can be applied in 
many ways. In a simple application, it can measure the 
speed of an external object. In a more complicated set- 
ting, it can give feedback in a motor control applica- 
tion. Here we explain the operation of the high-speed 
input peripheral, or HSI, and how you can use it to 
monitor events. 

HSI Overview 

The HSI associates time values with external 
events. Depending on the contents of the HSl_MODE 
register, the HSI can be configured to monitor four dif- 
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Figure 1. Block Diagram of the 8XC196KC/KD's High-Speed mput (HSI) 

Peripheral 



ferent types of events: rising edges, falling edges, both 
rising and falling edges, or a series of eight consecu- 
tive rising edges. 

When an event occurs, it is loaded into a 7 X 20-bit 

FIFO buffer queue (Figure 1 ). Eight state times later, 
the event is loaded into a holding register, provided 
that register is empty. The event can then be read from 
the HSLSTATUS and HSI_TIME registers. However, 
events are cleared from the FIFO buffer when the 
HSLTIME register is read. Therefore, care must be 



taken to read HSLSTATL'S before HSI_TIME, other- 
wise the HSI_STATUS information will be lost. 

Once an event is cleared, the eariiest entry in the 
FIFO buffer is loaded into the holding register. 
Depending on where the event is in the FIFO buffer, 
up to eight state times may be needed to load it into the 
holding register. 

Additional events that occur before the holding reg- 
ister is cleared are held in the FIFO buffer. An event 
that enters an empty FIFO buffer with an empty hold- 
ing register takes eight state times to enter the holding 
register: an event already in the FIFO buffer, but wait- 
ing for the holding register to be cleared, will enter 
immediately. 

Reading HSI Events 

Although events can be read in several ways, the 
most common way is to use an interrupt, in all, three 

interrupts can be used to read 

HSI events. 

The first interrupt is the 
HSI data-available interrupt, 
or INT02. This interrupt is 
triggered either when an 
event is loaded uuo the hold- 
ing register or when the HSI 
FIFO buffer is full. In the 
first case, an interrupt pend- 
ing bit is set when an event 
moves from the FIFO buffer 
to the holding register. In the 
second case, an interrupt 
pending bit is set after six 
entries are made into the 
FIFO buffer, filling the buffer. 
Bit lOCl .7 determines 
which condition will cause the interrupt: Clearing this 
bit selects the first case, which is an event being loaded 
into the holding register; setting the bit selects the sec- 
ond case, a filled buffer. 

The second interrupt available for reading HSI 
events is the HSI FIFO 4 interrupt, EMTIO. With this 
interrupt you can process more than one entry at a time 
while minimizing the chance of the FIFO buffer 
becoming overloaded and, therefore, an event being 
missed. The interrupt pending bit is set when the l^Tl^ O 



7x20-Bit 
FIFO 



Holding Register 



HSI TIME 
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buffer loads the fourth event of the seven it can hold. 

The third type of interrupt is the HSI FIFO buffer- 
full interrupt, INT 14. It has the highest priority of the 
three and, in effect, is the same as FIFO 4 interrupt. 
The interrupt pending bit is set when the FIFO buffer 
is loaded with its sixth event. 

Using the PTS 

Once you choose the interrupt that best suits your 
application, you must write a service routine to read 
the events. 

In some cases, it makes better sense to use the 
peripheral transaction server (PTS) to process the 
interrupt. The PTS is an efficient way to read events 
without bogging down the CPU with a long interrupt- 
service routine. Also, the PTS can read events fix)m the 
holding register faster than a normal interrupt service 
routine can. 

In particular, the PTS should be used when trigger- 
ing an interrupt using the second or third interrupt 
options; that is, INT 10 or 1NT14. That's because the 
PTS is tailored for transferring blocks of data, which is 
the correct way to handle interrupt INTIO or ENT14. 
However, if you select the interrupt that's triggered by 
loading the holding register, use a standard interrupt 
service routine rather than the PTS. 

To be serviced by the PTS, an interrupt goes to the 
PTS vector, which contains the location of the PTS 
control block. The program then jumps to the PTS 
control block (Table 1). 

Within the control block, a variable, PTSDST, con- 
tains the address in memory that stores event data. 
Another variable, PTSCOUNT, decrements for each 
PTS cycle imtil reaching zero, indicating the end of a 
PTS cycle. The end of the cycle, in turn, generates an 
end-of-PTS interrupt, which points to the normal inter- 
rupt service routine vector. Thus, among its other func- 
tions, the service routine should update the PTS con- 
trol block. 

As an example, consider the steps needed when 
using the HSI data-available intemipt to monitor rising 



TMe 1. PTS Control Bloek for MSI Mode 



Unused 



PTSBLOCK = 07H 



Unused 



Unused 



PTSDST (High) = XXXXH 



PTSDST (Low) = XXXXH 



PTSCON = 6AH 



edges, make speed calculations and then transmit the 
result back through the serial port (Figure 3). The first 

step is to initialize both the serial port and the HSI 
unit. Using the serial port in mode 1 and HSl.O, initial- 
ization code should contain the following settings: 



/Valid Hwindows are 0, 1 and 15 
(selected with WSRO-3) . 
; 16-bit bus width and ready pin 
controls wait states 
8067H ;Bit 15 set to select internal 
clock source; 
;baud rate is 9600 
(corresponds to 8067H in mode 1) 
;HSI.O will capture rising edges. 
/•Timer 1 overflow interrupt and 
HSI data-available interrupt 
; enabled . 

;No interrupts enabled in 
interrupt mask 1 
;HSI.Q enabled as high-speed 



BAUD RATE 



HSI_MODE = OIH 
INT MASK = 05H 



INT MASKl 



lOCO = OIH 
input 



OOH 



I0P0RT2 = 03H 
SP CON = 09H 



; Timer 1 overflow generates INTOO, 
P2.0 selected for serial 
;and transmit 

;P2.0 selected for transmit, 
P2 . 1 selected for receive 
; Serial mode 1 selected, RXD 
enabled 



The next step is to write an algorithm to process the 
HSI routines. In this case, the routine is interrupt-dri- 
ven. When an event occurs, the program jumps to the 
HSI data-available interrupt, calculates the time and 
sends the results to the serial port. In addition, because 
timer 1 overflow is used as the 17th bit of the timer, the 
HSI routine must monitor the additional count in the 
timer overflow routine as well as other conditions 
described further on. Figure 2 shows the program flow. 



Table 2. 196KC/KD Interrupt Vector Sources and Locations 



Interrupt 
Number 


Interrupt 
Vector 


Interrupt Source(s) 


Interrupt Vector 
Location 


PTS Vector 
Location 


INT14 


HSI FIFO buffer full 


HSI sixth entry 


203CH 


205CH 


INTIO 


HSI FIFO buffer 4 


HSI FIFO buffer fourth entry 


2034H 


2054H 


INT02 


HSI data available 


HSI sixth entry or HSI 
holding register loaded 


2004H 


2044H 



The next step is to write the mterrupt routine. Doing 
that successfully takes understanding the timer over- 
flow and interrupt timing. This is especially true when 
using the overflow and the data-available interrapts 

together. 

For example, when monitoring events using the HSI 
and timer 1, if an event occurs at FFFFH, it is possible 
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Figure 2. Example of Main Program Flow 

that the timer overflow interrupt could be processed 
first. If that happens, and both interrupts are enabled 
such a sequence would increment the timing calcula- 
tion. 

To understand how this happens, consider the time 

it takes for an HSI event to cause an interrupt: When 
an event triggers an HSI, it takes at least eight state 
times to go from the FIFO buffer to the holding regis- 
ter. If an event occurs on tlie overflow boundary, at 
least eight state times must pass before the correspond- 
ing interrupt-pending bit is set. The timer overflow 
interrupt, however, is set on the overflow boundary. If 
the current instruction plus the next instruction take 



less than eight state times, then the timer overflow 
interrupt occurs first. 

This problem can be solved within the HSI interrupt 
service routine. Before jumping to an interrupt service 

routine, test if the HSI time equals FFFFH. If it does, 
then see if the timer overflow interrupt is pending. If it 
is, process the interrupt normally. If not, the timer 
overflow interrupt has occurred and needs to be 
accounted for. The results can be sent out via the serial 
port by writing to the SBUF register in horizontal win- 
dow 15. 

Figure 3 shows how to handle an HSI interrupt. 



I holding 
register loaded 




Vector to interrupt 
service routine 




No 



Yes 



Decrement HSI 
overflow count* 






Calculc 
event tin 
H$l overt 


ite HSI 
ne using 
ow count, 



*Note: Do not change global Timer 1 overflow count. 

Only adjust the HSI overflow count that is used. 
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Figure 3. Sample HSI Interrupt Service Routine 
Block Diagram. 
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In summary, when using the HSI unit to moni- 
tor events: 

■ Decide how many HSIs you will need. 

■ Decide on an algorithm for reading the HSI 
events, including which type of interrupt to 
use. The choices are data available, fourth 
entry or FIFO buffer full. Also decide 
whether to use the peripheral transaction 
server (PTS) to process the interrupts. 

■ Initialize the HSI by writing to the correct 
registers and making sure to be in the cor- 
rect horizontal window. 

■ If using the PTS, write the correct values to 
the PTS control block. 

■ Initialize the serial port if you are planning 
to use it to transmit the HSI results. 

■ Write the appropriate code into your inter- 
rupt service routine(s). Make sure that you 
write the interrupt locations into their cor- 
rect vector locations. 

■ Put code into proper areas of memory, start- 
ing the main code at 2080H. 

■ Run the code. 

For more information about the HSI, refer to 
the 8XC196KC/8XC196KD Users Manual 
(order # 272238) or the ApQlHUyER. software 
(order #272216). 
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The target board that comes with the Project 
Builder evaluation kit for the 8XC196KD 16-bit 
microcontroller normally executes code downloaded 

from a PC. In this case, commands from the PC are 
used to start executing the code. But the same target 
board can also be used in standalone fashion. For that, 
you simply load your application code to an SRAM or 
EPROM on the board, change one jumper setting, reset 
the board, and execute yoiu" own code. 

Normally, the board executes monitor code, called 
RISM — burned into the one-time-programmable ROM 
on the 8XC196KD— which interfaces the ECM96 
monitor on a PC. Upon reset, the controller looks to 
memory location 2018H for a chip configuration byte. 
In the standard mode, location 2018H is in the internal 
memory and the RISM code begins executing internal- 
ly at 2080H. When the user gives a "go" coimnand, the 
RISM jumps to AOOOH, which is the start of the user's 
code. 

In the standalone mode, the RISM monitor resides 

in memory locations 2000H to 9FFFH. Thus, the dif- 
ference between the standard and standalone modes is 
whether the code from 2000H to 9FFFH is located 
internally or externally (Figure 1). 

To run in standard mode, the code is run from the 
internal memory. In that case, pin EA# is connected to 
Vcc by leaving the jumper El on the board unconnect- 
ed. In standalone mode, the code is run externally. For 
that, you must disable the on-board RISM by connect- 
ing jumper EI to AB, in effect grounding EA#. In 
doing fliis, you locate the chip configuration byte at 
201 8H and your code at 2080H externally (Figure 2). 
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Figure 1. Internal Execution Memory Map 
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Figure 2. External Execution 
Memory Map 



Memory Matters 

Normally, the microcontroller 
can address up to 64 Kbytes of 
memory using its 16 address lines 
(Figure 3). Because an 8-Kbyte 
SRAM (shipped with the demo 
board) uses 1 3 address lines, AO to 
A 12, loading code at address 
2000H is the same as loading it at 
OCOnOllor OAOOOI {(Figure 4). 
riie standalone mode exploits this 
feature as the following examples 
show. Also, Table 1 summarizes the 



possible standalone modes wifli (Af- 
ferent memory sizes. 

Because execution starts at 
2080H, that's the place to load your 
code if you vrant to run in stand- 
alone mode. This can be tricky. The 
RISM code for the target board sits 
tetween 2080H and 9FFFH. "fet we 
must locate the code in external 
memory at the same locations while 
internal memory is being used; that 



is, when pin EA# is high (El 
unjumpered). Because this same 
memory space is used for the on- 
board RISM, the problem is how to 
locate code at 2018H, 2080H and 
above in external memory. If we 
switch the EA# pin to force this 
region to external memory, we can 
no longer commtmicate with the PC 
because we have disabled the RISM 
located in the on-board ROM. 
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Figure 4. 8XC196 Connections to External 8-Kbyte SRAM 

The solution is to "trick" the 
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Figure 3. 8XC196 Connections to External SRAM 



memory into thinking that the con- 
troller is addressing locations 
2018H, 2080H and above when 
loading code to the external SRAM. 
Because the internal memory ends 
at 9FFFH, and only 1 3 address lines 
are used with an 8-Kbyte SRAM, 
address AOOOH looks like OOOOH to 
the external SRAM. 

You simply put the chip configu- 
ration byte at A018H and start your 
code at A080H. This locates the 
code at 0080H on the SRAM. As 
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mentioned, because only 13 address 

lines are used, 2080H looks like 
0080H to the SRAM. During reset 
with EA# pin low (El tied to AB), 
the microcontroller will fetch from 
201 8H. Again, because the 8-Kbyte 
SRAM has only 13 address lines, 
address 201 8H looks to it like 
001 8H. Consequently, your applica- 
tion code starts executing at 2080H, 
which is 0080H on the SRAM. So 



Table I. Standalone Mode and Different Memory 



Device 


Piogram with 


Start code at 


8-KB SRAM 


Target Board 


A080H 


16-KB SRAM 


Target Board 


AOBOH 


32-KB SRAM 


Target Board 


A080H 


64-KB SRAM 


(not possible in standalone mode) 


EPROM 


Programmer 


2080H 
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Note: 

A14-A15 are not connected, XXXO 0000 0000 OOOOB. Ttierefore, OAOOOH is the same as 2000H 
for the SRAM. When code is loaded to OAOOOH it actually is written to 2000H of the SRAM. 
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Figure 5. 8XC196 Connections to 16-Kbyte SRAM 



E^ier with EPROM 

Using EPROM in standalone 
mode is much easier than using 
SRAM. With EPROM you must 
bum the code into the exact loca- 
tions, put the chip configuration reg- 
ister at 201 8H, and start your code 
at 2080H. Then place the EPROM 
into tiie socket, make sure that the 
jumpers are correct for your type of 
EPROM, jumper the EA# pin for 
external execution, and press reset, 
whicii causes the controller to exe- 
cute code from external memory. 



after downloading your code to 
AOOOH, disconnect from the PC, 
change E 1 to AB, and press reset. 

When using a 16- or 32-Kbyte 
SRAM, the same technique applies 
(Figures 5 and 6). Here the SRAM 
has only 14 address lines, so 
address AOOOH appears the same as 
2000H. When the controller tries to 
run the program at locations 
A018H and A080H, these appear as 
201 8H and 2080H, respectively, on 
the address bus. You simply down- 
load the user code to AOl 8H and 
A080H, install the jumper on the 
EA# pin, and press re^ 
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Figure 6. 8XC196 Connections to 32-Kbyte SMAM 



CAN, the In-Vehicle Protocol That Could 



Article ID# 1007 

Circuits, sensors and other electronic components 
in a typical car or truck number in the hundreds and 
are on the rise. But in many cases, individual electron- 
ic subsystems arc separately wired to a control module, 
giving rise to wire harnesses that are heavy, bulky and 
difficult to design and install. Because each harness 
uses its own connectors, the potential for failures is 
high, and pinpointing these failures is time-consuming 
if not impossible. To the dismay of manufacturers, this 
system of point-to-point wiring makes adding other 
electronic features to vehicles expensive and difficult. 

To skirt the need for multiple wiring harnesses, 
designers have developed multiplexed networking pro- 
tocols to mo\ e electronic data along a single data path, 
or bus. Instead of separate harnesses, a shared network 
carries information to individual modules that control 
flinctions like anti-lock braking, turn signals and dash- 
board displays. The pre-eminent protocol specification, 
and prime candidate for standardization, is CAN 2.0. 

CAN Can 

CAN, or Controller Area Network, is a high-speed 

serial communications networking protocol for elec- 
tronic subsystems in cars and trucks. Standards organi- 
zations, including the Society of Automotive 
Engineers (SAE) in the United States, the International 
Standards Organization (ISO) in Europe and the 
Japanese Society of Automotive Engineers (JSAE), are 
looking seriously at CAN as a possible standard. 

To define network ftinctionality, the SAE has divid- 
ed the various implementations of automotive serial 
communications into A, B and C classes. CAN is a 
class C, or high-speed, protocol. That means it handles 
large amounts of data rapidly, usually for real-time 
control systems for engine control, powertrain control 
and braking. Class C protocols can transmit data at 1 
Mbit/second, transferring data almost instantaneously. 

Class B networks are intended for data communica- 
tions throughout the vehicle. They carry data, such as 
engine temperature, that is generated in electronic sub- 
systems and must be passed to other subsystems. This 
data doesn't control the subsystems and is not trans- 
mitted in real time. Data speeds typically range 
between 10 and 40 KB/sec. 

The Class B protocol development has received 



much attention because of a decision by the California 
Air Resources Board (CARB) to mandate on-board 
diagnostics for emission control testing. In this way, 
state testing centers will be able to plug their comput- 
ers into a vehicle to check its emissions equipment. 

Class A protocols handle low-priority applications 
operated by the driver's command, such as headlights 
and electric windows. This protocol typically operates 
at data rates below 10 KB/sec. 

The protocol requirements for in-vehicle network- 
ing differ from those for telecommunications and data 
processing. In-vehicle systems need a high degree of 
error detection, low latency and the flexibility to 
change the number of modules on the bus. To its cred- 
it, the CAN protocol qualifies for Class A, B or C 
operation. 

The CAN protocol manages the flow of messages 

using a technique called carrier sense, multiple access 
by collision detection using arbitration (CSMA CD/ A). 
Within a multimaster serial-bus architecture, priori- 
tized messages are sent at random moments in time. 
Contention for the bus by multiple messages is 
resolved by arbitration, where a message identifier 
travels along the bus bit by bit until the highest priority 
message gains control. Advantages of this type of pro- 
tocol are that several subsystems can report at one time 
and their data processed continuously. 

Intel's Part 

Robert Bosch GmbH developed the CAN protocol 
in the early 1 980s. Intel worked with Bosch on the first 
chip for the CAN protocol, the 82526. Introduced in 
1988 and reaching full production status in 1989. the 
82526 was the first high-speed, production implemen- 
tation of CAN. Since then, Intel has released an 
enhanced version, the 82527. 

The 82527 silicon handles all communication func- 
tions, including message transmission, reception, and 
error detection and confinement. In this way, it fi'ees 
the host microcontroller to handle other functions, like 
engine control or anti-lock braking. This feature is an 
important attribute of the 82527 and dilferentiates it 
from more primitive CAN devices that leave commu- 
nication management to the host microcontroller. 

Fabricated with Intel's CHMOS III technology for 
maximum performance and integration, the 82527 
operates over the automotive temperature range of -40 



to +125 degrees Celsius. Other CAN devices are also 
available from Intel as well as other venders. Future 
devices are expected to reduce the cost of building sys- 
tems that use the CAN protocol. 

Where CAN Stands 

European cars with CAN in-vehicle networks have 
been produced since 1991. In Europe, the ISO has 
adopted CAN as the preferred high-speed networking 
protocol for vehicles. European automakers say they 
need the CAN protocol now, particularly for luxury 
models that have highly distributed electronic subsys- 
tems. For example, where U.S. automakers often inte- 
grate engine and transmission functions into a single 
module, European automakers have separate injection, 
ignition and transmission modules. 

In the United States, major car and heavy truck 
makers have also evaluated CAN. Truck manufacturers 
are especially interested because of the distributed 
nature of the truck subsystems. The SAE Truck and 
Bus Control and Communications Network subcom- 
mittee selected the CAN protocol as the foundation for 
J 1939, the Class C networic for truck and bus applica- 
tions. The subcommittee voted to adopt CAN because 
of its: 

■ Ability to handle high-speed data and increase 
subsystem reliability 

■ Ability to send data fast enotigh for future needs 

■ Cost-effective implementation and availability 

in silicon (like the 82527) 

■ Synergy with the work of other standards 
organizations 

With the SAE Truck and Bus subcommittee's deci- 
sion to use CAN, the protocol is being designed into 
U.S.-built trucks and buses. As a result, the hundreds 
of wires between subsystems have been reduced to a 
few, with the effect of speeding manufacturing, simpli- 
fying diagnostics and enhancing the capacity to add 
options. Many of these designs will reach production 
and be on the road in the 1 994 model year 

Both the JSAE and the SAE Class C Task Force 
have evaluated CAN and are likely to adopt it as a 
standard. In addition to the automotive market, the 
CAN protocol is being designed into non-automotive 
networking products like factory automation equip- 
ment, elevators, medical equipment and in-home elec- 
tronic communications systems. 



Automakers and Intel on 
ABS: "Full-Speed 
Ahead!" 

Article ID# 1008 

One of the fastest growing markets in automotive 
electronics is for the microcontrollers used in anti-lock 
braking systems. The overall value of microcontiollers 
in North American automotive vehicle-control applica- 
tions, of which ABS is a significant portion, will grow 
from about $70 in 1993 to $190 by the year 2000, 
acccwding to BIS Strategic Decisions of Luton, 
England. 

Several factors are contributing to this growth. For 
one, U.S. and foreign governments are encouraging 
auto manufacturers to make cars safer. Consumers also 
are demanding more safety-related features as these 
become increasingly important to them. As a result, 
more than 40 percent of passenger ears and light-duty 
trucks built in North America have ABS, according to 
Tier One, an automotive industry research firm in 
Mountain View, California. By 2000, predicts Tier One, 
this figure will approach 1 00" ». Projections indicate 
similar growth for .Japan and Europe. 

Finally, the cost of anti-lock braking systems (ABS) 
is dropping. Intel, for example, expects that the prices 
to car makers for four-wheel ABS will fall below $150, 
down from the current range of $250 to $400. 

What is ABS? 

ABS prevents a vehicle's wheels from locking when 
its brakes are applied suddenly. Such locking causes a 
car skid. ABS works by modulating, or pulsing, the 
brakes when the driver applies them hard. This auto- 
matic pulsing improves stopping distances and gives 
better steering control. As a result, it gives a driver 
greater control over the car during sudden braking. 

Advanced systems combine anti-lock braking with 
traction control. By adjusting the limited-slip differen- 
tial or throttle control during acceleration, traction con- 
trol helps the vehicle steer better and gain traction, 
especially on wet or slick surfaces. 

While combined ABS/traction control (ABS/TC) 
systems are more expensive and less in demand than 
ABS alone, manufacturers expect to equip increasing 
numbers of car models with these combined systems as 
costs drop and consumers become more aware of their 



Continued from page 17 

benefits. Robert Bosch GmbH estimates that by the 
year 2000, 20% of the total ABS business will be for 
ABS/TC systems. 

The Elements of ABS 

The three key electronic elements of ABS are wheel 

speed sensors; brake modulators; and the electronic 
control unit (ECU), w hich is the system's electronic 
brain. A microcontroller, like those Intel supplies to 
ABS module manufacturers, acts as the central pro- 
cessing unit. Residing within the ECU. the microcon- 
troller monitors wheel speed and road conditions every 
five to seven milliseconds, processing tills information 
as it gets it from speed sensors coimected to a vehicle's 
wheels. 

In adverse driving condition, the microcontroller 
controls the modulators which, in turn, adjust tiie pres- 
sure applied to the brakes. By varying that pressure, 
and in particular reducing it if the wheels begin to 
lock, the system prevents the tires fi-om skidding. 

Today, most ABS-equipped passenger cars have 
four-wheel systems, in which sensors collect data 
fi"om — and the system controls — all four wheels. Most 
light-duty trucks with ABS have two-wheel systems, 
which control only two of the four wheels. Forecasts 
suggest, however, that by the middle of this decade vir- 
tually all systems will be four-wheel types, offering 
superior vehicle handling and more control than two- 
wheel types. 

ABS and traction control systems use either 8- or a 
16-bit microcontrollers to process data. The main dif- 
ference is the amount of data processed simultaneous- 
ly, with a typical 16-bit device processing data up to 10 
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16-bit microcontroller can handle more data faster and 
more accurately. Thus, a 16-bit device not only oper- 
ates more quickly, yields greater braking resolution 
and improves performance, it can even govern a trac- 
tion control system at the same time. 

Today, many systems use 8-bit devices. However 
most are moving to the higher processing speeds, high- 
er integration and improved performance of newer 16- 
bit controllers. As the cost of 16-bit devices continues 
to decrease, they are becoming affordable for even 
economical ABS designs. 

Intel's Role 

Intel's Automotive Operation is the largest supplier 
of microcontrollers for passenger car and light-duty 
truck ABS and traction control systems. The first inte- 
grated ABS, introduced by ITT Automotive (formerly 
Alfred Teves GmbH) in 1983, used an Intel 8051 8-bit 
microcontroller. A year later, Robert Bosch GmbH 
introduced a systCTi using an Intel 16-bit microcon- 
troller. 

Today, more than 75 percent of all new 16-bit ABS 
and ABS/TC designs in North America and Europe 
use Intel microcontrollers. In all, Intel has captured 
more than 40 percent of the market volume in the pas- 
senger cars. Among the leading ABS and traction con- 
trol systems suppliers that use Intel controllers are 
ITT Automotive, Bosch, Kelsey-Hayes, Bendix, 
Knorr-Bremse, Wabco and Lucas Girling. In turn, 
these suppliers provide modules to car manufacturers 
including Ford, General Motors, Chrysler, BMW, 
Mercedes Benz, Volkswagon, Saab, Porsche, Audi, 
Renault, Nissan and Volvo. 



What Designers Demand 

The performance features that ABS designers need 

in 1 6-bit controllers such as Intel's MCS* 96 family 
include a watchdog timer, on-chip memory for software 
control and diagnostic functions, a dedicated hardware 
interrupt controller and I/O manager for real-time event 
control, and an A/D converter. 

Besides performance and price, module designers 
look for architectural "headroom" when selecting a 
microcontroller. That is, they prefer a microcontroller 
with several variations and the capacity to provide 
expanded system performance. Toward this end, by 
choosing a family of microcontrollers that shares the 
same architecture, designers can use different models in 
various ABS modules without costly and time-consum- 
ing redesigns and recertifications. Software in particular 
takes a large investment. Because manufacturers put 
much time and money into developing fail-safe sys- 
tems, compatibility between software and microcon- 
troller architecture is of prime importance. 

Intel's newest 1 6-bit controllers provide that compat- 
ibility across products and, by offering numerous com- 
binations of features and processing capabilities, 
expand a module's designs. A module supplier can, for 
example, design an ABS incorporating the simplest 
member of the family for cost-sensitive design and 
grow to one incorporating the most complex module to 
meet higher system needs such as those required by 
ABS/TC systems. 

And because the architecture in each case is the 
same, the software can be reused. In this way, the mod- 
ule supplier saves time and money, while reducing its 
risk, by not having to rewrite expensive software for 
each kind of ABS module. In adcUtioa, because the 



company's designers need be familiar with only one 
basic architecture, the company benefits from shorter 
learning curves and a shorter time-to-market. 

ABS and Beyond 

Four-wheel ABS is expected to be a standard feature 

on virtually all passenger cars and light-duty trucks by 
the end of the decade. Because of the rapid commoditi- 
zation of this market, system and component suppliers 
will push aggressively for rapid cost reductions. 

0\ er the longer term, suppliers will focus on how 
ABS and ABS/TC will evolve. Most industry observers 
and participants feel that this evolution is toward vehi- 
cle dynamics control (VDC). Going well beyond the 
capacity of ABS/TC systems, VDC systems control the 
pitch, roll and yaw of a vehicle in any handling situa- 
tion. 

For example, imagine a car. traveling too fast as it 
enters a sharp corner covered by black ice. A VDC sys- 
tem will control engine, transmission, braking, suspen- 
sion and steering responses to help the driver maneuver 
the vehicle safely. Robert Bosch, a leader in this tech- 
nology, predicts that VDC systems will account for 
roughly 5 percent of the total vehicle control (ABS, 
ABS/TC and VDC) market by the year 2000. 

Intel not only offers the most comprehensive 1 6-bit 
product line in the industty for ABS and ABS/TC, it 
has products well-suited for the emerging VDC market 
as well. As these and other systems evolve, Intel's auto- 
motive operation will continue to provide a broad range 
of standard and application specific logic and memory 
products for the automotive and heavy-vehicle industry. 



Intel Automotive History 



1979: Intel focuses on automotive electronics as five 

car makers and suppliers approach the company to 
develop an electronic engine controller (EEC). This 
controller will become the "grandfather" of the 8096. 

1980 to 1981 : Ford and Intel strike EEC deal. 
Dialogue begins with a leading anti-lock braking sys- 
tem (ABS) manufacturer regarding an 8-bit controller 
for ABS. Auto activity is managed through Intel's 
Consumer Operation. 

1982: Intel starts development of the 8096AH. 

1983: The 8061 EEC reaches production, and volume 
shipments begin. The first ABS based on Intel's 8-bit 
8051 microcontroller is introduced and becomes the 
seed of Intells success with ABS. A leading European 
car supplier begins using Hxe 8048 and 8049 for engine 
control. 

1984: Leading European ABS supplier approaches 
Intel for development of a 16-bit ABS controller, 
which becomes the 8X9X. Dialogue with Japan 
begins. EEC production reaches high volume. 

1986: Intel forms Automotive Operation. It enters a 
joint venture with Bosch to produce the Controller 
Area Network (CAN) protocol. American manufactur- 
ers start to use the 8051 to control such dashboard 
functions as instrumentation, clocks and entertainment 
equipment. 

1987: Intel's Automotive Operation begins three- 
prong application focus on engines, networks and 

brakes. ABS and engine controller volumes ramp 
sharply. Development of 16-bit CMOS ABS controller 
begins. Both 8- and 1 6-bit devices gain widespread 
design wins. 

1988: 16-bit CMOS controller for ABS hits produc- 
tion volume. Intel wins design at another North 
American ABS supplier. 

1989: Intel ABS customer portfolio now includes four 
of the top five ABS suppliers using either 8- or 16-bit 
Intel architectures. The 82526 CAN controller reaches 
production status. 



1 990: 8XC 1 96KR family launch targeted at the mar- 
ket for brakes. Four of five top ABS suppliers now 
design 1 6-bit systems. 

1991: ABS controller business becomes top revenue 
source. Bosch-Intel Design Group (BiDG) is formed. 
Intel wins suppUer quality awards from three automo- 
bile makers or suppliers. First production car wifii 
CAN is introduced. 



Revenue History 




Automotive Operation Intel Corporation 


($M) 


($B) 


1989 115 


3.13 


1990 122 


3.92 


1991 127 


4.78 


1992 140 


5.84 


1993 155 


8.78 



Manufacturing Locations 

Wafer Fabrication 

■ Fab 4, Aloha, Oregon 

■ Fab 6, Chandler. Arizona 

■ Fab 7, Rio Rancho, New Mexico 
Assembly Plants 

■ AOl, Penang, Malaysia 

■ A03, (ANAM). Seoul, South Korea 

■ A02, Manila, Philippines 
Test Facilities 

■ T03, Penang, Malaysia 



1992: The 82527 CAN+ is introduced in August. Intel 

Automotive wins tlash-memory design-in at U.S. auto 
maker. The 87C196KT, an enhanced ABS controller, 
becomes available. 

1993: Intel achieves two major shipment milestones 
by delivering 20 million ABS and 40 million engine- 
control microcontroller. Also, the 87C196JT, a low- 
cost, highly integrated ABS controller is introduced. 
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New Bnbedded Control 

FaxBack* Service Documents 



New/Updated as of August, 1994 
Title Number 

56L TSOP Programming Adapters: E28F016SV, 

E28F016SA & DD28F016SA Flash File™ 

Memories 2226 

56L SSOP Programming Adapters: 

DA28F016SV, DA28F016SA Flash File™ 

Memories 2259 

Flash: 2/4/8-Mbit Boot Block 

Family Overview 2263 

8XC196NT: User's Manual Errata 2338 

8XC186/C188: Flash Memory Interface 

Recommendations .2342 

Altera "Dear Customer" letter to Intel PLD/FPGA 

Customers 2354 

Article: MCS* 96: Intel's Automotive Operation 

and the ABS/Traction Control Market ...2356 
Article: CAN: Intel's Automotive Operation and 

In-Vehicle Networking 2357 

8XC196KR/JR/KQ/JQ: 

1B00H-1BDFH Bug 2358 

MCS® 96 processor: C 196 LOG, LOG10, POW 

and EXP routines ..2361 

Embedded 1386^1^ Processor: 

Hardware and Software Development Tools 

Line Card 2765 



After Honrs Activity 




A 10- and a 20-ft. ladder cross an alley and 
lean against the buildings as shown. They inter- 
sect at a height of 6 ft. Without using graphical 
means, cdculate the width of the alley. 

(Hint: The alley is less than 6 ft. wide.) 
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Article ID #1009 

Change identifiers have been used since 1990 to distinguish revisions, or stoppings, of embedded control 
devices. Older devices have no change identifiers. On most devices, the change identifier is the last character in the 

FPO number, which is typically a nine-character code on the second line on the top of the device. An example FPO 
number is "L1234567D," in which "D" is the change identifier. On some devices, such as the 8XC51SL-BG, the 
change identifier is a separate line item and uses several characters. For example, change identifier "SWOl 1" identi- 
fies the B-3 stepping of the 8XC51SL-BG. 

This article lists change identifiers, errata, and design considerations for recent steppings of embedded control 
products. For many of these devices, complete errata listings or explanations are available from the FaxBack* ser- 
vice. The "Ref " column in each table lists FaxBack service document numbers for errata lists and explanations, and 
"For More Information" at the end of this article has a complete list of related document numbers and titles. 

MCS® 51 Microcontroller Family Errata and Design Considerations 

This list covers the most recent steppings of the MCS® 51 microcontrollers. A complete list of the errata for all 
steppings is available on the FaxBack service (document #2632). 



Table 1. MCS- 51 Microcontroller Family Errata and Design Considerations 



Device 


Step 


Change 
Identifier 


Errata and Design Considerations 


Ref. 


8051 AH/8031 AH 




A 

A 


1 . External interrupt errata 


2154 


C-3 


B 


No known errata 




80C51BH/80C31BH 


C 


none 


1 . Reset lod(up problem 

2. High IPD If C does not equal B.7 before 

going into powerdown 

3. ROM verify mode fails 

4. Steam passivation problem on plastic parts 




C-1 


none 


1 . High IPD if C does not equal B.7 before 
going into powerdown 

2. ROM verify mode fails 




D 


Dor 2 


No known errata 




87C51 


D 


A 


No known errata 


2106 


80C52/80C32 


C 


none 


1 . RSI/ONCE mode problem 




A 


A 


No known errata 




83C51 FA/80C51 FA 


C 


none 


1 . PGA errata 


2528 


87C51 FA 


C 


none 


1. RSI/ONCE mode problem 

2. PCA errata 


2528 


D 


A 


No known errata 


2107 


8XC51FB 


A 


none 


1 . PCA errata 


2528 


B 


A 


No known errata 


2111 
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Table 1. MCS® 5 J Microcontroller Family Errata and Design Considerations (Continued) 








Device 


Step 


Change 
Identifier 


irmta and Design Considerations 


Ref. 






8XC51FC 


A 


none 


1 . Port 1 , 2, 3 problem — asychronous port 
reset not supported 

2. Failed ESD qual testing 


2028 








B 


none 


No known errata 








8XC51GB 


B 


none 


1 . Reset polarity changed to active low 

2. Port 1 reset value changed to all zeros 


2032 
2032 








B-2 


none 


No known errata 








8XC152JX 


B 


none 


1 . AE/RDN race condition 

2. Receive FIFO is not cleared when receiver 

is enabled 

3. DMA errata 

4. SDLC flag recognition errata 


2030 

2118 
2035 








C 


none 


No known errata 








8XC51SL-BG 


B-3 


SW011 


1 . GATEA20, RCL hardware speedup processing 

2. Powerdown current stabilization 

3. Port 2 address mux 

4. KSI powerdown wakeup interrupt 

5. Reset errata 


2008 

2114 








B-4 


SW062 


1 . GATEA20, RCL hardware speedup processing 

2. Powerdown current stabilization 

3. Port 2 address mux 

4. KSI powerdown wakeup interrupt 


2008 






8XC51SL-AH/AL 


' A-0 
A-1 
A-2 


AA 
BA 
CA 


1 . Power-down current stabilization 

2. System power management errata 




2048 




MCS® 96 Microcontroller Family Errata and Design Considerations 






This list covers the most recent steppings of the MCS® 96 microcontroller. Complete lists of the errata for all 

steppings are available on the FaxBack service for the 8X9XBH (#2134), the 8XC196KB (#2548), the 8XC196KC 
(#2136), the 8X196KD (#2315), the 8XC196KR (#2527), and the 8XC196NT (#2178). 


Table 2. MCS® 96 Microcontroller Family Errata and Design Considerations 








Device 


Step 


Change 
Identifier 


Errata and Design Considerations 


Ref. 






8X9XBH 


D 


D 


1 . Indexed 3-operand multiply 

2. HSl FIFO 

3. Reserved location 201 9H 

4. RESET and the QBD pins 

5. Software RESET timing 

6. Using T2CLK for Timer2 


2134 








E 


E 


1 . Indexed 3-operand multiply 

2. HSl resolution 

3. Reserved location 201 9H 

4. Reserved location 201 OH 


2631 
2140 
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TaMe 2. MCS^ 96 Mwrocantroller Ftmily Errata and Desipi ComidemtUms (Continued) 



Device 




Change 
Identifier 


Bnala and Design Considerations 


Ref. 


8XC196KB 

OyvO 1 S70i\D 1 \JI1\0 1 


Ail 
mi 




■1 UCI Q/q Ctatp 

2. CMPL with RO 


2548 




B 


B 


1 . Divide during HOLD or READY 

2. SIO framing error 

q QIO Rl flan 

4. DJNZW instruction 

5. ALE glitch 

D. inoi ui viut; uy tJiy 1 ! L 


2568 


8XC196KB/KB16 


B 


B.D 


1 . Divide during HOLD or READY 
4. Missed EXTINT P0.7 

3. HSLMODE divide-by-elght 

4. Oscillator sensitivity 


2122 
2049 
2192 




C-0 

C-1 


E 

F. G 


1. Missed EXTINT P0.7 

2. HSLMODE divide-by-eight 


2049 

2192 


8XC196KC 






The number following each entry in this 
list Is a cross-reference to the applicable 
section of FaxBadc service document 
#2136. 


2136 




all 




Design Considerations 

1 . Indirect shift count value 

2. Write cycle during Reset 


116 
147 






R 1 
D- 1 


o 


1 . Divide error during hold 

2. NMI during PTS skips address 

3. QBD glitch during powerup 

4. ONCE mode entry 

5. Oscillator startup 

6. Reset hysteresis 

7. Missed EXTINT P0.7 

8. HSLMODE divide-by-eight 

9. Aborted PTS skips next byte 


109 
123 
163 
214 
215 
216 


2049 

2192 
2328 




B-3 


DorE 


1 . Divide error during hold 

2. NMI during PTS skips address 

3. QBD glitch during powerup 

4. Reset hysteresis 

5. Missed EXTINT P0.7 

6. HSLMODE divide-by-eight 

7. Aborted PTS skips next byte 


109 
123 
163 
216 


2049 
2192 
2328 




D 


H,J,L,M 


1. Missed EXTINT P0.7 (80C196KC only) 

2. HSI MODE divide-by-eight. 

3. IPD Hump 


2049 
2192 

£.0\ 1 


8XC196KD 


A-1 


B 


1. Missed EXTINT P0.7 

2. HSLMODE divide-by-eight 

3. IPD Hump 


2049 
2192 
2311 




B 


D,E 


1 . Missed EXTINT P0.7 (8301 96KD only) 

2. HSLMODE divide-by-eight 

3. IPD Hump 


2049 
2192 
2311 


8XC196KR/JR/KQ/JQ 


A,C 


A, C 


Design Considerations 

1 . P6_REG not updated immediately 


2527 
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Table 2. MC0 96 Microcontmiler Famify Errata and Design Considerations (Continued) 



Device 


Step 


Change 
Identifier 


Errata and Design Considerations 


Ret. 


8XC196KR/JR/KQ/JQ 
(Continued) 






2. Write cycle during reset 

3. EPA timer reset/write conflict 

4. Valid time matches 

5. CLKOUT 

6. Indirect shift operation 

7. Internal RAM powerdown leakage 

8. A/D latchup 

9. INST operation 

10. KQ/JQ memory map 






A 


A 


Errata 

1 . Oscillator noise sensitivity 

2. Slave programming mode 

3. A/D abort 

4. PTS with other interrupts 

5. PTS/NMI conflict 

6. Data output register cleared when mode 
register is written 

7. Divide error during Hold/Ready 

8. SIO Mode 

9. Remap mode on EPA3 

10. Serial port framing error 

1 1 . EPAIPV value multiplied by 2 

12. EPA_MASK1/EPA_PEND1 must be 
written as words 

1 3. Interruptable block move (BMOVI) 






A,C 


A, C 


1 . loh2 = - 6 mA 






C,D 


CD 


1 . Cannot access external locations 1 BOOH-1 BDFH 




8XC196NT 


D 


D 


Design Considerations 

In bus controller modes 1 and 2. in 8-bit bus 

mode, the upper address lines need 

to be latched 

1 . Illegal Opcode Interrupt vector not taken. 

2. Aborted interrupt vectors to lowest priority. 

3. PTS request during interrupt latency. 




8XC196MC/MD 


B 


B 


No known errata 




8XC196NP 


A 


A 


1 . Illegal Opcode interrupt vector not taken. 

2. Aborted interrupt vectors to lowest priority. 

3. PTS request during interrupt latency. 





8XC186/8XC188 Family Errata and Design Considerations 



Table 3. 8XC186/8XC 188 Family Errata and Design Considerations 



Device 


Step 


Change 
Identifier 


Errata and Design Considerations 


Ref. 


80C186A, B 


none 




1 . Non-contiguous Interrupt Acknowledge cycles 

2. ERROR* processing during FWAIT 

instructions 

3. Input high voltage requirement on SRDY and 
ARDY pins 

4. Interrupt Status Register (DHLT and 
Timer Interrupts) 

5. Bus preemption errata (HOLD/HLDA 

protocol) 

6. 80C1 88 RFSH# pin output timing 


2096 


80C186XL 


A 


none 


Never put into production 




B 


A 


1 . INTx/INTAx in Cascade Mode 


2025 


C 


B 


No known errata 




80C18eEA/80L186EA 


A 


A 


1 . Low hysteresis on RESIN# pin 

2. TEST/BUSY#, RD#/QSMD#, LCS#, and 
UCS# input low voltage 

3. INTx/INTAx in Cascade Mode 


2025 


B 


B 


1 . INTx/INTAx in Cascade Mode 


2025 


80C186EB/80L186EB 


A 


A or none 


1 . Entry into ONCE mode 

2. Low hysteresis on RESIN* pin 

3. SINT1 input not latched internally 

4. Ready input during INTA# bus cycle 

5. CLKOUT transitions on the 
rising of CLKIN instead of the 
falling edge 

6. I/O ports 1 and 2 initialize to 
Port instead of Peripheral 
function (documentation error) 

7. INTx/INTAx in Cascade mode 


2025 


B 


B 


1 . INTx/INTAx in Cascade Mode 


2025 


oUOl ODCL' 


A 

A 


A 

A 


1 . Early exit from Reset (with high Vcc, or 
low temperature, or both) 

2. Powersave Mode initialization at Reset 




B 


B 


No known errata 





2& m,ism mammmiMmMfi^mm^m^a' 



For More Information 

The following FaxBack* service documents contain errata lists and explanations. 



Title Number 
MCS® 51 Controller Errata 

MCS 51 : Errata and Design 

Considerations 2632 

IVICS 51 : 1991 8 bit Microcontroller Book 

Errata 2123 

MCS 51 : 1992 8-bit Datasheet Errata 2165 

MCS 51 : FX-Core ALE Disable 

Datasheet Errata 2308 

8XC51 FX: QFP Pin 39 Change 2124 

8XC51 FX: PCA / TIMER2 Errata 2528 

8XC51FX: Hardware Description Errata 2017 

87C51 FA: D Step 2107 

87C51 FB/83C51 FB: B Step 21 1 1 

87C51 FC: Data Sheet Errata 1 2024 

87C51 FC: Data Sheet Errata II 2020 

87C51:DStep 2106 

87C54/80C54: Data Sheet Errata I 2022 

87C54/80C54: Data Sheet Errata II 2021 

8051/31 AH: Shrink C-Step External 

Interrupt Errata 2161 

80C31/51BH: D-Step Marking 2015 

87C51GB: A-1 & B Errata & Design 

Consider 2032 

8XC51SLAH/AL Errata 2048 

80C51 SL-BG: Errata Version 2.6 2008 

80C51SL-BG: Product Preview 

Data Sheet Errata 2630 

80C51 SL-BG: Errata 2130 

80C51 SL-BG: Reset Errata 2144 

80C152: SDLC Flag Recognition Bug 2035 

8XC152: External Demand DMA Bug 2129 

8XC152: Global Serial Channel Bug 2030 

8XC152: DMA Bug 2118 

8XC152: Errata and Clarifications III 2043 

MCS® 96 Controller Errata 

8XC1 96KB/KC/KD,8XC1 98,8XC194: 

HSI Events (9 or greater) 2052 

Project Builder: Manual Errata 2170 

8XC196KB: History and Errata ..„.2548 

* 80C196KB/83C196KB: B-0 to C-1 

Stepping Conversion 2316 

8XC196KB: ALE Glitch 2568 

8XC196KB/KC/KD: HSI_MODE 

divide-by-eight 2192 

8XC196KB/KC/KD: Missed EXTINT 

Interrupt Problems on P0.7 2049 

8XC196KC: 1991 Handbook Errata 2131 

8XC196KC: HSI PTS Handbook Errata 2141 



Title Number 
MCS® 96 Controller Errata (Continued) 

8XC196KC: Bug List 2136 

8XC196KC/KD: Powerdown 

Current (IPD) Hump 2311 

8XC196KC/KD: 1992 User's Manual 

Errata 2570 

8XC196KD: Bug List 2315 

8XG196KR/JR/KQ/JQ: Errata 2527 

8XC196KR Eval Board EPA Remap 

Warning 2120 

8X0196: Hold/Ready DIV/DIVB Problem....2122 
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